1. Technical Field of the Invention
The present invention relates to interoperability between end-user devices designed for use in similar but different kinds of telecommunications systems where the system infrastructure for one system is not necessarily deployed and, more particularly, between a first system that primarily uses a single protocol throughout and a second system that uses different protocols between its servers and between its servers and its devices.
2. Discussion of Related Art
Such a first system is exemplified by an Internet Protocol Multimedia Subsystem (IMS) according to the third generation partnership project (3GPP) while such a second system is exemplified by a Wireless Village (WV) system of the Instant Messaging and Presence Services (IMPS) Initiative. Therefore, an exemplary but non-limiting application of the present invention enables WV clients to interoperate with IMS clients.
FIG. 1 shows a prior art Wireless Village system architecture model. According to the Wireless Village “System Architecture Model version 1.1”, it is a client-server based system, where the server is an IMPS server and the clients can be either mobile terminals, or other services/applications for fixed PC-clients. For interoperability, the IMPS servers and gateways are connected by a server-to-server protocol (SSP) defined in various WV specifications now published at version 1.1, which may be found at www.wireless-village.com. For instance, FIG. 1 shows a first Wireless Village server 10 communicating using the SSP with a second Wireless Village server 14. Likewise, the first and second Wireless Village servers 10, 14 are able to communicate using the SSP over communication lines 16, 18 with a Proprietary Gateway 20. Each of the Wireless Village servers 10, 14 constitute central nodes in the Wireless Village system. As shown in FIG. 1, a WV server 10, 14 comprises application service elements 22 that are accessible via service access points (SAPs) 24, 26 in the servers 10, 14.
As shown in FIG. 2, the application service elements comprise a presence service element 28, an instant messaging element 30, a group service element 32, and a content service element 34. The functional description of each of these application service elements may be found in the above-mentioned Wireless Village specification entitled, “System Architecture Model, version 1.1”. Similarly, as shown in FIG. 2, a service access point (SAP). 35 serves as the interface between the WV server and its environment. It has interfaces to WV clients, other WV servers, the mobile core network, and proprietary gateways to non-WV servers. Such a proprietary, non-WV server 36 is shown in FIG. 1 coupled to the proprietary gateway 20 by a signal line 38.
The functionality of such a Service Access Point 35, as shown in FIG. 2, includes authentication and authorization for communicating with Wireless Village embedded clients 40, 42, 44 (see FIG. 1) using a client-server protocol (CSP) access 39 also defined in the Wireless Village specifications, version 1.1. The SAP 35 also includes Service Discovery and Service Agreement functionality for CLP (command line protocol) access 46 to command line interface (CLI) clients 48, 50, 52 (FIG. 1). The command line interface client uses text messages to communicate with the WV server. The functionality provided by such a client might be a subset of the functionality provided by an embedded client 40, 42, 44. An example of a CLI client is a mobile terminal that uses SMS to communicate with the Wireless Village server.
User profile management is another functionality provided in the Service Access Point 35, as shown in FIG. 2, in providing SMCNP (Server Mobile Core Network Protocol) access 54 to a mobile core network 56 (FIG. 1). Finally, a Service Relay function is provided by SSP access 58 in order to route all service requests and responses among the servers through the server-to-server protocol (SSP).
The SSP service relay is discussed further in the Wireless Village specification entitled “Features and Functions, version 1.1”, as also shown in FIG. 3 hereof. According to the WV specification, Home Domains such as Home Domain A 64 and Home Domain B 66 must have a direct SSP connection to interoperate with each other so that client A connected to Home Domain A 64 can communicate with the services offered by the Wireless Village network, which may include accessing information of client B 70 connected to Home Domain B 66. However, Wireless Village also supports the routing of “service relay” between the home domain and a Primary Service Element (PSE), meaning a primary SE of an IMPS service for a client. In other words, PSE may be in the home domain of the client or in a remote domain.
For example, the upstream route from Home Domain B 66 to a PSE 72 for a particular client is shown in FIG. 3, where the PSE domain 72 that provides the actual service element, e.g., an instant messaging (IM) service, is shown remotely. Each intermediate domain relays the service request to the next node. The intermediate nodes (H(1) WVS, . . . , H(n) WVS) act as the “logical” service provider role for each downstream domain, and act as the “logical” service requester role for each upstream domain, as suggested in FIG. 3.
At each domain, the SAP should maintain a service table that keeps track of the service agreements to appropriately relay the SSP service request on a per-service basis and forward the SSP service result on a per-domain basis. Being the “logical” service provider, the SAP should maintain a session record for each service requester. Being the “logical” service requester, the SAP should maintain a transaction record for each service provider. The SAP should maintain a transaction table to map each requested transaction from its service requester of the initiated transaction to its service provider. The transaction table should have a unique match for each transaction. Therefore, the service relay flow and result forward flow at each SAP is clearly and uniquely identified by the transaction flows.
The SAP at the home domain should appropriately map a CSP/CLP service request from the client to an SSP service request and/or map the SSP service result to a CSP/CLP service result for the client.
This defined interoperability as per the Wireless Village specifications is satisfactory as far as it goes, but the interface between the proprietary gateway 20 and the proprietary server 36 is not well defined. It should preferably employ a non-proprietary solution for interfacing on the line 38 between the proprietary instant messaging or presence service server 36 and the proprietary Wireless Village gateway 20. In certain cases, such as the IMS (IP Multimedia Subsystem) proposed in UMTS Release-5, the addressing modes are completely different, in that the IMS takes an SIP (session initiation protocol) communication protocol approach, and IMS also uses http (hypertext transfer protocol) as transport protocol for certain services (i.e. HTTP probably with SOAP utilised for group management, access control manipulation, etc), while Wireless Village uses transport protocols that are different (WSP, http, https). So it would appear to require to have an interoperability functionality to change the semantics of the messages.
WV Messages are defined in XML scripts with HTTP as transport. See “SSP-Transport binding,” version 1.1 “Client-Server Protocol Transport Bindings,” version 1.1, “Server-Server Protocol XML Syntax Document,” version 1.1, “Client-Server Protocol DTD and Examples” version 1.1 of the Wireless Village Mobile IMPS Initiative. In IMS the transport can be either SIP or HTTP and the normal procedures performed according to WV specifications are different. The WV XML scripts are self contained data structures that include session and transaction information. In IMS this functionality is partly performed by the transport protocol and the rest is included in the body of the messages.
Moreover, as mentioned above, the IMS according to 3GPP primarily uses a single protocol (SIP) that is standardized by the IETF and the WV servers use two protocols as also described above, i.e., SSP and CSP/CLP. To compound the problem, there may be some operators who deploy the IMS but not the WV, and other operators who deploy the WV but not the IMS but nonetheless wish to offer their customers access to the other service.